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Abstract 

The  time  transfer  procedure  presently  used  for  the  realization  of  TAI  is  based  on  the  common 
view  approachy  using  the  CGGTTS  data  computed  by  an  internal  software  of  the  time  receivers . 
We  choose  here  another  approach  and  analyze  the  raw  data  available  in  the  RINEX  files  produced 
by  GPSIGLONASS  geodetic  receivers .  We  concentrate  our  analysis  on  the  use  of  GLONASS  P- 
code  measurements .  Because  the  frequency  emitted  by  each  GLONASS  satellite  is  differenty  the 
measurements  must  be  corrected  for  their  frequency -dependent  receiver  hardware  delays.  These 
delays  can  be  computed  either  from  the  CGGTTS  files  or  directly  from  the  raw  P-code  data.  We 
show  that  the  first  approach  is  better  than  the  second  one.  After  this  correction ,  time  transfer  (using 
the  GLONASS  P-codes)  is  realized  with  a  rms  of  about  2  nanoseconds  for  a  1-day  session  between 
two  receivers  distant  of  a  few  hundred  of  kilometers. 


INTRODUCTION 

The  use  of  the  GLONASS  P-codes  for  time  transfer  is  very  promising,  as  already  shown  by  different 
studies  ([2]  [3]  [4]  [6]  [7]).  In  all  the  mentioned  studies,  the  time  transfer  results  were  obtained  us¬ 
ing  CGGTTS  (GPS/GLONASS  Time  Transfer  Standard)  data  files  provided  by  receivers  designed 
for  time  transfer  applications.  The  CGGTTS  files  ([1])  contain  the  clock  differences  between  the 
GLONASS/ GPS  system  time  and  the  local  clock  of  the  time  laboratory.  These  differences  are 
computed  by  the  receiver  software  for  the  satellites  given  in  the  international  tracking  schedules 
distributed  by  the  BIPM  (Bureau  International  des  Poids  et  Mesures)  and  are  used  for  the  com¬ 
putation  of  TAI.  On  the  other  hand,  the  International  GLONASS  Experiment  (IGEX)  ([10])  gave 
access  to  RINEX  files  from  about  25  receivers  in  the  world.  Part  of  these  combined  GPS/ GLONASS 
receivers  are  driven  by  precise  frequency  standards,  and  some  of  them  contribute  also  to  the  real¬ 
ization  of  TAI.  We  have,  therefore,  investigated  the  possibility  of  performing  time  transfer  using 
the  GLONASS  P-code  data  given  in  these  RINEX  data  files. 

Using  a  common  view  method,  we  determine  the  receiver  clock  offsets  and  consequently  the  time 
transfer  between  the  external  frequency  standards  driving  these  receivers.  Compared  to  the  method 
based  on  CGGTTS  files,  this  method  allows  to  work  with  a  higher  number  of  data  points  (about 
3000  per  day)  and  allows  to  control  each  aspect  of  the  correction  terms  from  the  raw  data  to  the 
final  product. 
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Figure  1:  GPS/GLONASS  sites  used  in  this  study. 


In  ([8]),  the  final  precision  of  the  time  transfer  between  two  3S-Navigation  R100  receivers  distant 
of  a  few  hundred  of  kilometers,  obtained  using  the  precise  ephemerides,  was  about  10  ns.  The 
main  limitation  was  the  receiver  hardware  delays  which  are  different  for  each  satellite  because  of 
the  satellite  dependency  of  L\  and  frequencies.  Due  to  the  fact  that  calibration  values  are  not 
available,  a  first  approach  consisted  in  estimating  the  corrections  of  each  satellite  directly  from 
the  time  transfer  results  produced  by  each  satellite  separately.  However,  this  adjustment  was  not 
perfect  due  to  the  fact  that  we  estimated  the  offset  between  the  results  of  the  different  satellites 
on  a  time  span  of  only  1  day.  In  ([9]),  we  used  the  CGGTTS  delays  determined  on  a  time  span  of 
two  weeks  and  showed  that  the  final  precision  of  the  time  transfer  improves  to  1.8  ns  for  a  typical 
1-day  session  between  2  receivers  distant  of  a  few  hundred  of  kilometers.  The  disadvantage  of  this 
approach  was  that  it  could  only  be  applied  for  time  receivers. 

In  order  to  overcome  this  limitation,  we  try  in  this  paper  to  determine  these  differential  receiver 
hardware  delays  directly  from  the  raw  P-code  measurements,  but  now  using  several  days  of  mear 
surements  and  we  compare  the  results  with  those  obtained  from  the  CGGTTS  data. 


DATA  SET  DESCRIPTION 

We  have  used  the  RINEX  data  of  GPS/GLONASS  receivers  belonging  to  IGEX  network,  and 
operating  at  the  same  time  as  time  laboratories  participating  in  the  realization  of  the  international 
atomic  time  scale  (TAI)  (see  Figure  1): 

•  BRUG,  located  at  the  Royal  Observatory  of  Belgium,  equipped  with  a  combined  GPS/GLO¬ 
NASS  multi-channel  receiver  R100-30T  from  3S-Navigation,  connected  to  a  H-maser  for  the 
geodetic  part,  and  to  a  cesium  clock  HP5071A  (=UTC(ORB))  for  the  participation  to  TAI; 

•  NPLC,  located  at  Teddington  (Greater  London,  UK),  336  km  far  from  Brussels,  equipped  with 
a  combined  GPS/GLONASS  multi-channel  receiver  R100-40T  from  3S-Navigation,  connected 
to  a  H-maser  (=UTC(NPL))  for  both  the  geodetic  part  and  the  participation  to  TAI. 

As  shown  in  ([8]),  the  R100  receivers  exhibit  regular  artificial  discontinuities  in  the  computed 
receiver  clock  synchronization  errors,  which  make  it  impossible  to  perform  RINEX-based  precise 
time  transfer  for  more  than  1  day.  This  is  a  typical  situation  for  all  receivers  from  this  manufacturer. 
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RECEIVER  HARDWARE  DELAYS 

Figure  2a  shows  that  the  time  transfer  signal  obtained  using  a  single  day  of  observations  with 
precise  ephemerides  still  presents  some  small  jumps  or  curvatures  not  attributable  to  the  H-maser. 
These  are  due  to  changes  in  satellite  configuration  and  to  the  uncorrected  receiver  hardware  delays 
associated  with  the  different  satellites  observed. 

We  have  used  two  different  methods  for  determining  the  hardware  delays.  The  first  one,  already 
presented  in  ([9]),  is  based  on  the  fact  that  the  receivers  used  in  our  experiment  (BRUG,  NPLC) 
also  provide  CGGTTS  files  to  the  BIPM,  so  we  used  the  time  transfer  results  provided  by  these 


Satellite 

number 

hardware  delays 
CGGTTS  (ns) 

hardware  delays 
RINEX  (ns) 

Differences 

1-  ' 

-0.4 

3.6 

4 

3 

-2.9 

-2.3 

0.6 

4 

-0.4 

-1.4 

1 

6 

-0.9 

-2.3 

3.2 

7 

0.0 

0.0 

0 

8 

-0.5 

1.4 

3.9 

9 

7.2 

7.9 

0.7 

10 

1.4 

5.3 

3.9 

11 

-2.7 

1.8 

4.5 

13 

6.9 

7.7 

0.8 

15 

-2.1 

-4.4 

2.3 

16 

-3.8 

-4.7 

0.9 

17 

4.0 

8.5 

4.5 

22 

6.0 

6.2 

0.2 

Table  1:  Hardware  delays.  Satellite  7  is  chosen  arbitrary  as  the  reference  one. 


CGGTTS  files  to  estimate  the  differential  receiver  hardware  delays.  When  using  CGGTTS  files, 
there  are  no  jumps  because  these  results  give  the  offset  between  GPS  time  and  the  1  pps  (1  pulse  per 
second)  signal  provided  by  the  laboratory  clock.  Using  the  CGGTTS  files,  the  calibration  delays 
can  now  be  determined  using  a  longer  time  span  containing  more  simultaneous  observations.  Note 
that  we  cannot  assert  that  the  hardware  delays  are  the  same  for  both  geodetic  data  and  the 
CGGTTS  data;  this  depends  on  the  receiver  architecture  and  will  be  tested  here  by  comparing 
with  the  hardware  delays  obtained  directly  from  the  raw  data  given  in  the  RINEX  files.  Clock 
resets  are  not  problematic  because  they  do  not  alter  the  differential  hardware  delays  computed 
from  the  RINEX  files.  This  means  that  we  can  determine  the  calibration  delays  using  RINEX 
data  over  a  time  span  longer  than  1  day. 

We  test  both  methods  on  the  baseline  BRUG  -  NPLC.  A  period  of  14  days  (51351-51365  MJD 
(Modified  Julian  Date)  corresponding  to  GPS  weeks  1015  and  1016)  has  been  used  to  determine 
the  calibration  delays  from  the  CGGTTS  files  (see  ([9])  for  details)  as  well  as  from  the  RINEX 
files.  Table  1  lists  the  hardware  delays  determined  by  both  methods. 

In  Figure  2,  we  have  plotted  the  time  transfer  results  between  BRUG  and  NPLC  for  the  first  day 
of  the  GPS  week  1016  (corresponding  to  MJD  51357).  The  first  part  of  the  graph  shows  results 
which  are  not  corrected  for  the  frequency  dependent  receiver  hardware  delays.  In  this  case,  the 
rms  of  the  differences  is  equal  to  2.6  ns.  The  second  part  is  corrected  for  the  receiver  hardware 
delays  using  CGGTTS  files  and  the  corresponding  rms  is  equal  to  1.8  ns.  The  last  part  is  corrected 
for  receiver  hardware  delays  obtained  from  the  RINEX  files  and  the  corresponding  rms  is  equal 
to  2.0  ns.  We  can  say  that  this  correction  removes  the  curve  variations  induced  by  the  variable 
‘mean’  hardware  delay,  corresponding  to  the  mean  of  the  delays  of  the  observed  satellites  at  each 
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time.  But,  as  seen  from  the  graphs,  although  our  correction  sometimes  reduces  the  jumps  and 
variations,  it  leaves  some  variations  at  other  times.  This  is  due  to  the  limited  accuracy  of  the 
computed  receiver  hardware  delays:  the  computed  receiver  calibration  errors  between  the  different 
satellites  are  of  the  same  order  of  magnitude  (from  0  to  10  ns)  as  the  noise  level  of  the  clock 
differences  computed  with  any  satellite  (2.5  ns).  We  see  also  that  the  results  using  the  CGGTTS 
files  for  calibration  are  better  than  the  ones  using  RINEX  files  (r ms  of  1.8  ns  vs  2.0  ns).  Indeed, 
even  if  the  RINEX  files  provide  a  larger  number  of  observation  points,  the  noise  level  is  higher 
than  with  the  CGGTTS  files  (standard  deviation  of  5  ns  instead  of  2  ns).  This  is  due  to  the  data 
smoothing,  which  is  part  of  the  procedure  applied  to  compute  the  CGGTTS  files. 
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Figure  2:  Time  transfer  (BRUG-NPLC).  (a)  Hardware  delays  not  corrected,  rms  =2.6  ns  (b)  Hardware 
delays  corrected  by  CGGTTS  files,  rms  =1.8  ns  (b)  Hardware  delays  corrected  by  RINEX  files,  rms  =2.0 
ns. 
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Figure  3:  Time  transfer  (BRUG-NPLC). 


COMPARISON  BETWEEN  GLONASS  AND  GPS  RESULTS 

In  Figure  3,  we  have  plotted  the  time  transfer  between  BRUG  and  NPLC  for  the  first  day  of 
the  GPS  week  1016.  We  see  that  the  use  of  the  GLONASS  P-code  (rms  of  1.8  ns  and  maximum 
difference  of  11.8  ns)  reduces  the  noise  level  with  a  factor  between  2  to  3  with  respect  to  the  use 
of  GPS  C/A  code  (rms  of  4.4  ns  and  maximum  difference  of  31.9  ns). 

Figure  4  shows  the  frequency  stabilities  of  the  frequency  transfer  performed  with  GPS  C/A-codes, 
GLONASS  P-codes  and  GPS  phases.  The  GLONASS  P-code  results  show  a  better  stability  than 
GPS  C/A-code  results  at  short  time  scales  (below  1  hour).  This  is  a  direct  consequence  of  the  lower 
noise  level  of  the  GLONASS  P-code  compared  to  the  GPS  C/A-code.  At  longer  time  scales  (larger 
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than  1  hour),  we  observe  the  opposite  situation  due  to  the  imperfect  correction  of  hardware  delays 
in  the  GLONASS  P-code  results,  inducing  small  undulations  of  the  curve  (as  seen  in  Figure  3), 
which  reduces  the  frequency  stabilities.  The  results  based  on  GPS  carrier  phases  have  frequency 
stability  highly  superior  to  the  results  based  on  codes  (GPS  or  GLONASS).  However,  although 
carrier  phases  offer  a  huge  potential  for  the  frequency  transfer  applications,  they  still  depend  on 
the  information  in  code  data  to  determine  the  absolute  synchronization  offset  (see  ([5])  for  more 
details). 

CONCLUSION 

We  have  used  RINEX  data  from  combined  GPS/GLONASS  receivers  involved  in  the  IGEX  cam¬ 
paign  to  investigate  the  performances  of  the  GLONASS  P-codes  for  time  transfer  applications.  We 
pointed  out  that  it  is  necessary  to  correct  the  P-codes  for  the  receiver  hardware  delays  which  are, 
for  the  GLONASS  data,  different  for  each  satellite.  Receiver  calibrations  are  unavailable  at  the 
present  time;  the  determination  of  the  receiver  hardware  delays  for  each  satellite  must  be  done 
during  the  computation  of  the  synchronization  errors.  However,  due  to  the  noise  of  measurements 
and  the  variability  of  the  hardware  delays,  this  determination  cannot  be  done  precisely  enough 
with  only  1  day  of  data.  Using  several  days  of  data  would  allow  a  more  reliable  determination 
of  the  satellite  dependent  hardware  delays.  The  CGGTTS  files  made  available  by  some  IGEX 
receivers  give  a  long  time  series  of  synchronization  errors  determined  on  individual  satellites  and 


Figure  4:  Frequency  stabilities  of  the  different  time  transfer  results  of  Figure  3. 


allow  easier  determination  of  the  differential  biases  between  the  satellites.  Another  approach  is 
to  use  the  RINEX  files  themselves  in  order  to  use  geodetic  receivers  and  not  only  time  receivers: 
in  this  case,  clock  resets  occur,  but  are  not  problematic  because  they  do  not  alter  the  differential 
hardware  delays  between  the  satellites.  More  problematic  is  the  fact  that  the  RINEX  raw  data  are 
more  noisy  than  the  smoothed  CGGTTS  data,  even  with  a  larger  number  of  observation  points  for 
the  RINEX  files.  This  leads  to  a  better  determination  of  the  hardware  delays  with  the  CGGTTS 
files  than  with  the  RINEX  files  (rms  of  1.8  ns  instead  of  2  ns  for  a  typical  1-day  session  between 
two  stations  distant  of  a  few  hundred  of  kilometers).  However,  even  with  the  knowledge  of  these 
calibration  delays,  a  precise  frequency  transfer  with  RINEX  data  will  be  restricted  to  1  day  due  to 
the  jumps  at  the  day  boundaries  due  to  the  daily  resets  of  the  3S-Navigation  receivers.  If  a  time 
transfer  is  needed  for  a  time  span  longer  than  1  day,  the  receiver  clock  jumps  must  be  monitored 
with  an  external  time-interval  counter. 


95 


We  can  conclude  that  the  present  geodetic  GLONASS  receivers  driven  by  a  stable  frequency 
standard  can  be  used  for  time  transfer  applications  only  if  (1)  the  satellite-dependent  hardware 
delays  are  regularly  monitored  and,  (2)  the  1  pps  output  is  monitored  in  order  to  measure  the 
clock  discontinuities. 
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